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(57) ABSTRACT 

A data center for providing access to subscriber information 
from a remote enterprise network in real-time is presented. 
The data center includes a data network interface system for 
interfacing with a data network and a login system, which 
includes a login server and a data center messaging server. 
The login server receives a request inputted by a subscriber 
on a remote access device across the data network to access 
the subscriber information and authenticates the subscriber 
and the remote device, while the data center messaging 
server hosting the subscriber information. Upon authenti- 
cating the subscriber and the remote device, the login server, 
accesses the subscriber information on the data center mes- 
saging server and provides the subscriber information to the 
remote access device in response to the received request. 

13 Claims, 10 Drawing Sheets 
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DATA CENTER FOR PROVIDING For purposes of this application, a corporation or other 

SUBSCRIBER ACCESS TO DATA entity, public private, or otherwise, is referred to as an 

MAINTAINED ON AN ENTERPRISE "enterprise." As used herein, an enterprise represents any 

NETWORK entity maintaining or controlling information at a remote 

S location from a subscriber. Examples of enterprises include 

BACKGROUND OF THE INVENTION a secure corporate network, a dedicated server, or a publicly 

1 c«m «f T«„~«t™ accessible web site network. Other enterprises may be 

1. Field ot the invention , , , . . . , . - ^ . r . c ' 

. A . « i * . *i_ « u r • employed which maintain and control certain information as 

This invention generally relates to the field of commum- r ' . . , , c . , 1t . #u . 

. . c . i * may be appreciated by those of skill in the art. 

cations and information network management. More J rr 

particularly, the present invention relates to a novel system 10 certam s y ste ms have been employed to provide 

that allows remote end users to rapidly and securely access access to information maintained at an enterprise, none have 

information from a variety of subscriber devices using a provided for access by multiple devices including PDAs, 

centralized remote data center. ~ cellular telephones, personal computers, laptops, 

2. Description of Related Art „ MICROSOFT® Windows CE devices, and so forth Further, 
„ 4 . 4 . . . - j those systems discussed in the literature that provide lnfor- 
Recent innovations in wireless communication and ' , . u J . - . 

, . , . . , . „ j * j mation access to users employmg a limited set of input 

computer-related technologies as well as the unprecedented devfces haye sufifered fmm \ c ^ mil and data U J 

growth of Internet subscribers nave provided tremendous «, A ~ . - .j. A 

& . ... . . , a wt t problems. Accessibility issues involve providing access to 

opportunities in telecommuting and mobile computing. In ^ information b on / offerin ^/^^l 

fact, corporate entities and enterprises are moving towards on T . . . » . . ° , A f r . . 

*u • ic - + u w -* * * Intranet or other internal access scheme. A subscriber wish- 

providine their workforces with ubiquitous access to net- . . «« « .. . . , , r 

. j 4 v .. i_ r mg to review his or her e-mail on a laptop borrowed from a 

worked corporate applications and data, such as, for ?, . 4l . , . , * 4 f . . f 

i t IT i i « * * i j colleague frequently is denied access to the corporate lnfor- 

example, e-mail, address books, appointment calendars, & „ .Z 1 , * , . n . , » .f , .... 

l • r *■ x rr mation. Further, data latency universally mhioits the ability 

scheduling information, etc. , j * tt j • r * * *l • * 

„ . , . , . . , to access data. Users desire a fast response to the lnforrna- 

Hie problem with providing universal access to propn- ^ ^ ft desir ^ information on device ^ takes 

etary information is one of logistics. For example, it is lo ^ fifteen ^ to load is und6sirable . 

common for an individual to keep sets of addresses on . . ... 

different devices, such as work addresses on a personal . Additionally, certam .enterprises wish to have control over 
computer used at work, personal addresses on a home * formatl011 maintained on their network including main- 
computer, and commonly called telephone numbers on a 30 tamm * <P asf ™ ord and ^ ouni ^formation for the enterprise 
cellular telephone. Problems arise when the individual is at users ; }* 18 * herefore ^esirable for the enterprise to offer 
home and wishes to call or fax a work colleague, particularly sensitive data, such as subscriber information and 
when the individual does not have access to the work P^words to outside parties where the data may be corn- 
addresses from the home computer or any other available Promised. Security issues, such as corporate firewalls and 
device. Further, different urgent priority items, such as 35 of Idata must m many instances be maintained 
urgent e-mails, may be unavailable to a subscriber for an tolled by the enterprise rather than a third party, 
extended period of time if the subscriber is equipped only Certain enterprises also have particular needs and prefer- 
with a personal digital assistant (PDA) and a cellular tele- ences. For example, some corporate enterprises may main- 
phone unable to receive e-mail. a network that interfaces with offices in different 

Along with the problem of maintaining data in various 4 o countrie s, and depending on the person accessing the 
locations, users frequently have access to different devices, information, he or she may have a particular language 
each having different data access abilities and requirements. preference. Certain enterprises also find it highly desirable to 
For example, certain cellular telephones have speed dial or have a ^configurable interface to provide updated graphics, 
commonly called telephone numbers, but do not have the information, and presence to network users. These sub- 
ability to receive e-mail. Certain cellular telephone handsets 45 scriber interfaces ma y chaQ g e ra P idj y in some industries. A 
have the ability to receive alphanumeric pages, but some s y slem offering information access should therefore be 
cellular service providers do not support this feature while readily reconfigurable and offer subscriber interfaces struc- 
others do. Also, many PDAs do not have the ability to tared for the enterprise for use on a variety of input devices, 
receive over-the-air transmissions, but can synchronize with Such a system should be relatively easy to set up and 
a database, such as a database associated with a personal 50 maintain, and use readily available hardware and software 
computer and/or network. Other PDAs have the ability to wherever possible. Further, the system should provide for 
receive and edit e-mail messages. Some systems or networks data access tracking and efficient security and authorization, 
allow a subscriber to download her e-mail headers to a It is therefore an object of the current invention to provide 
remote device and read some portion or all of the e-mail. a system for offering convenient and efiBcient access to data, 
After reading the e-mail on the remote device, some systems 55 including e-mail, calendar/date book, and addresses. These 
delete the e-mail while others maintain the e-mail on the terms are commonly known in the art, wherein e-mail 
system until read or deleted at the home system. Hence the represents electronic mail deliverable in a recognized 
ability for a subscriber to access, maintain, and dynamically format, including attachments and other electronic mail 
utilize information is heavily dependent on the input device attributes. Calendar/date book data represents dates of 
employed by the subscriber. 60 meetings, appointments, holidays, or other noteworthy 

Further, certain organizations limit access to workers events maintained in a searchable database type format, 

having a need to know the information maintained. For Addresses represent information associated with contacts, 

example, many corporations control e-mail using a dedi- such as the contact's name, title, company, business address, 

cated server having restricted access, including using fire- business phone number, business fax number, home address 

walls and encryption. Access to this information requires 65 and/or phone number, cellular phone number, e-mail 

making the information available under conditions imposed address, and so forth. Access to the information should 

and maintained by the corporation. preferably be provided through a central location. 
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It is a further object of this invention to provide for access 
to the desired information using any of a variety of input 
devices, including but not limited to a personal computer, a 
laptop computer, a PDA, a cellular telephone, a two-way 
pager, and a MICROSOFT® Windows CE device. s 

It is still a further object of the present invention to 
provide a system that recognizes the type of device address- 
ing and requesting the information and to provide the 
information to the device in a proper format in accordance 
with the preferences of the enterprise transmitting the infor- 10 
mation. 

It is another object of the current invention to provide a 
central location for enabling a series of users to access 
information at various enterprises when said users employ 
various input devices. Such a central location should offer 15 
relatively robust access to the information desired, offer 
security for information maintained on the enterprise such as 
subscriber data and passwords, and provide for authentica- 
tion and access tracking. 

It is yet another object of the current invention to provide 2 o 
an interconnection between a central data location and an 
enterprise such that the interconnection can quickly, reliably, 
and efficiently transfer information, such as e-mail, calendar, 
and address data, between the central data location and the 
enterprise. 25 

It is a further object of the current invention to provide a 
remote enterprise architecture that supports inquiries from 
and responses to the central data location for use in a 
multiple subscriber and multiple input device data access 
scheme. The remote enterprise architecture should permit 30 
rapid access to the information and transmission of the 
information while simultaneously maintaining firewall, 
security, and encryption requirements. 

It is still a further object of the current invention to 
provide architectures, which are reliable and easy to use 35 
from both a software and hardware standpoint, and utilize 
where possible existing components to minimize system 
costs. 

It is yet a further object of the current system to provide 
a subscriber interface that is readily reconflgurable by an 40 
enterprise maintaining the information. Further, the sub- 
scriber interface should preferably provide enterprise data 
on various input devices and take into account enterprise and 
subscriber preferences when interfacing with a subscriber. 

It is another object of the current invention to provide a 45 
business model for supplying users with access to e-mail, 
calendar, and address information in a multiple input device 
environment when the desired information is maintained at 
a remote enterprise. 

SUMMARY OF THE INVENTION 50 
Accordingly, there is herein provided a data center that 
provides a central location for accessing, transmitting, and 
maintaining desired subscriber information, including 
e-mail, calendar, and contacts. The data center includes a 55 
login site and associated SQL server, an enterprise gateway 
server and associated SQL system. The arrangement dis- 
closed herein provides for remote login by users employing 
any of a number of subscriber input devices. The architec- 
ture provides for two levels of authentication, including an 60 
initial authentication for the data center and a pass through 
authentication to the enterprise network. The data center also 
preferably includes security, such as firewall hardware, and 
has the ability to translate received CDO commands into 
XML commands. 65 

The data center permits the authentication of a subscriber 
and access to a remote enterprise having a scalable, reliable, 
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and secure data platform, such as MICROSOFT® Exchange 
Server. Access to the remote enterprise is made through a 
dedicated connection such as an IPSEC or PPTP tunnel 
arrangement. The enterprise network is preferably main- 
tained by the party controlling the information and the 
connection, and thus the system supports access to the 
remote enterprise through the data center without the data 
center receiving and translating the subscriber information. 

The remote access device transmits or receives informa- 
tion over a data link, which is connected to a data center. The 
data center offers a central location for accessing and pro- 
cessing information from various remote enterprise net- 
works. The data center includes at least one login server, 
configured as a web server (e.g., MICROSOFT® US), 
having access to at least one attributes database server (e.g., 
SQL server). The login server identifies and authenticates 
the subscriber and verifies that the subscriber is associated 
with a particular enterprise. The login server refers to the 
attributes database server for the data necessary to perform 
these tasks, and thus the attributes database server performs 
data storage for account access purposes. The login runs 
individual active server pages that provide the requested 
information back across the data link to the subscriber. The 
data center may send data through a dedicated connection, 
which is preferably an IPSEC runnel through the Internet, a 
PPTP connection via the Internet, or it may send data 
through a non-Internet WAN transport mechanism. The 
Internet provides a powerful and readily accessible data 
transmission media. Addition of enterprise networks or data 
centers to an arrangement employing the Internet is rela- 
tively simple. The data link may also employ the Internet for 
subscriber access to the data center. 

Other objects, features, and advantages of the present 
invention will become more apparent from a consideration 
of the following detailed description and from the accom- 
panying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in 
and constitute a part of this Specification, illustrate an 
embodiment of the invention and, together with the 
description, explain the objects, advantages, and principles 
of the invention. In the drawings: 

FIG. 1 is a conceptual diagram representing the major 
components of the system; 

FIG. lAis a high level block diagram depicting the basic 
elements of an embodiment of the present system; 

FIG. IB is a high level block diagram depicting various 
elements of an exemplary communication system interfac- 
ing with a remote data center; 

FIG. 1C is a high level block diagram depicting the 
architecture of a remote data center; 

FIG. 2 is a functional block diagram depicting the authen- 
tication process; 

FIG. 3 is a high level block diagram illustrating the basic 
elements of the EGS; 

FIG. 4 is high level diagram depicting the connectivity 
between a data center and a plurality of enterprise network 
servers; 

FIGS. 5A, 5B are block diagrams illustrating embodi- 
ments of the implementation of a Virtual Private Network 
interconnecting a data center and a enterprise network; 

FIG. 6 is a diagram depicting the architecture of the RGS 
software components; 

FIGS. 7A and 7B are diagrams depicting alternative 
embodiments of the communications between a messaging 
server and an EGS; and 
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FIG. 8 illustrates the customization initialization proce- 
dure. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The following detailed description of the embodiments of 
the present invention refers to the accompanying drawings 
that illustrate these. Other embodiments are possible and 
modifications may be made to the embodiments without 
departing from the spirit and scope of the invention. 
Therefore, the following detailed description is not meant to 
limit the invention. Rather the scope of the, invention is 
defined by the appended claims. 

It will be apparent to one of ordinary skill in the art that 
an embodiment of the present invention, as described below, 
may be realized in a variety of implementations, including 
the software, firmware, and hardware of the entities illus- 
trated in the figures (i.e., remote access device 104, BSC/ 
MSC 106 and IWF 108). The actual software code or control 
hardware used to implement the present invention is not 
limiting of the present invention. Thus, the operation and 
behavior of the present invention will be described without 
specific reference to the actual software code or hardware 
components. Such non-specific references are acceptable 
because it is clearly understood that a person of ordinary 
skill in the art would be able to design software and control 
hardware to implement the embodiment of the present 
invention based on the description herein. 

FIG. 1 presents a conceptual overview of the design of the 
current system. From FIG. 1, a subscriber has access to an 
input device, which may be one from a class of input devices 
10 including, but not limited to, a cellular telephone 11, a 
personal digital assistant (PDA) 12, a MICROSOFT® Win- 
dows CE device 13, a desktop personal computer 14, or a 
laptop personal computer 15. Other devices may be 
employed, such as a two-way paging device, while still 
within the scope of the present invention. The important 
characteristic of the class of input devices 10 is that each 
device must have the ability to receive information. 

The input device transmits or receives information over a 
data link 16, such as a telephone line, dedicated computer 
connection, sateDite connection, cellular telephone network, 
the Internet, or other data connection. The data link 16 is 
connected to a data center 17, which offers a central location 
for accessing and processing information from various 
remote enterprise networks 22. Data center 17 provides 
users with access to information or data maintained at the 
enterprise networks 22. The data center 17 includes at least 
one web server 18 (e.g., MICROSOFT® Internet Informa- 
tion Server [IIS]) having access to at least one attributes 
database server (e.g., Structured Query Language [SQL] 
server) 19. The IIS server 18 identifies and authenticates the 
subscriber and verifies that the subscriber is associated with 
a particular enterprise. The IIS server 18 refers to the SQL 
server 19 for the data necessary to perform these tasks, and 
thus the SQL server 19 performs data storage for account 
access purposes. The IIS servers 18 process individual active 
server pages, or ASPs, that provide the requested informa- 
tion back across data link 16 to the user or subscriber. The 
data center 17 transmits data through a dedicated connection 
20, which is preferably an IPSEC tunnel through the 
Internet, or a PPTP connection via the Internet. The dedi- 
cated connection 20 is provided through data transmission 
media 21, which may be the Internet, a Wide Area Network 
(WAN), or any other media used for server communication. 
The dedicated connection 20 provides the robustness nec- 
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essary to update the subscriber and provide information in a 
reasonable time period. Use of a connection that is not 
dedicated can result in delays and service disruptions, and 
the Internet provides an example of a powerful and readily 
5 accessible data transmission media. Addition of enterprise 
networks 22 or data centers 17 to an arrangement employing 
the Internet is relatively simple. Note also that data link 16 
may also employ the Internet for subscriber access to the 
data center 17. 

10 In operation, the subscriber must first access the data 
center 17 using an access arrangement, such as a password 
verifying his or her identity. The subscriber makes a request 
into the subscriber device, such as a cellular telephone, to 
view data, such as his or her e-mail. The IIS server 18 

15 receives the request via the data link 16 and passes the 
request through the dedicated connection 20 and on to the 
enterprise network 22. The enterprise network 22 processes 
the request for e-mail and obtains the necessary data pur- 
suant to the subscriber preferences provided by the SQL 

20 server in the data center 17. For example, the subscriber is 
presumed to have established that if he or she desires e-mail 
through his or her cellular telephone, the information pro- 
vided should be only the first ten messages, alphabetized by 
the last name of the sender. In such a situation, the enterprise 

25 network 22 obtains the requisite information and transmits 
the data back through the dedicated connection 20, to the 
data center 17, and to the subscriber via data link 16 to the 
requesting subscriber input device. To accomplish this, the 
enterprise network 22 must include a server having a 

30 scalable, reliable and secure data access platform, such as 
MICROSOFT® Exchange Server, for ready access to the 
requested e-mail, calendar, or contact information. 

FIG. LA illustrates an embodiment of the present inven- 
tion. The embodiment allows subscribers to securely and 

35 remotely access a centralized data center 190, which acts as 
an intermediary to facilitate subscriber information residing 
in an independent enterprise network 403 in real time. In one 
implementation, a subscriber, by virtue of a remote access 
device 104, makes a request, across a network 100, to a data 

40 center 190, to supply subscriber information (e.g., messag- 
ing and collaboration information, such as electronic mail, 
appointment calendars, address/phone books) located in an 
enterprise network 403. The data center 190 receives the 
request, authenticates the subscriber, accesses the enterprise 

45 network 403, establishes a secure session with the enterprise 
network 403, retrieves the subscriber information, and for- 
mats the information in accordance with the display capa- 
bilities of the remote access device 104. The remote access 
device 104 may be connected to a "wireline" network (e.g., 

50 personal computer, kiosk, etc.) or may be connected to a 
wireless network (e.g., cellular phones, personal digital 
assistants [PDAs], MICROSOFT® Windows CE device, 
etc.). 

In another embodiment, as indicated by FIG. 1A, the data 
55 center 190 itself provides a central repository for the sub- 
scriber information (dashed-line). As such, the subscriber 
initiates a request in the remote access device 104 and the 
data center 190 receives the request, authenticates the 
subscriber, accesses the subscriber information, and formats 
6o the information -in accordance with the display capabilities 
of the remote access device 104. 

The features and details of the various embodiments of 
the invention will be described below. 
1. Remote Access Devices 
65 The remote access and retrieval of subscriber information 
resident in the enterprise network 403 is initiated by request- 
ing the information on a remote access device 104. 
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Generally, these requests are initiated by inputting an The IWF 108 is subsequently coupled to a system router 

address on a browser (or micro-browser) interface of the 110, which interfaces with other networks, such as the 

remote access device 104. The address partially identifies Public Switched Telephone Network (PSTN) and other 

the enterprise network 403 that the subscriber is associated Wide Area Networks (WANs) providing Internet- or secure/ 

with (i.e., company, employer,, etc) and the address may be 5 unsecure Intranet-based access. 

in the form of an HTTP URL (Hypertext Transfer Protocol 3. Data Center Configuration and Host and Enterprise 

Uniform Resource Locator). The remote access devices 104 Operations 

have communication capabilities, allowing them to interface Data center 190 acts as an intermediary to remotely and 

with wireless and wireline communication networks. In one securely collect, process, and format the information resid- 

implementation, the remote access devices 104 are wireless 10 ing in the enterprise network 403 and to present the infor- 

and include devices that are well-known in the art, such as mation on the remote access device 104 in real time, 

hand-held wireless phones, Personal Digital Assistants Generally, the desired information will be stored in a spe- 

(PDAs), MICROSOFT® Windows CE devices, and mobile cialized database/messaging server within the enterprise 

computers. Such devices operate in wireless networks that network 403, such as, for example, MICROSOFT® 

include, but are not limited to PSTN, CDPD, CDMA/IS-95, 15 Exchange Server 5.5. Such a database hosts electronic mail, 

TDMA/IS-136, MOBITEX, and GSM networks. address books, appointment calendars, and is capable of 

In addition, these remote access devices 104 generally groupware functionality, 

have graphical displays to accommodate their browsing As shown in FIG. 1C, the data center 190 comprises an 

capabilities. The remote access devices may use different interface network 120, a Login subsystem 140, and a Service 

markup languages to interpret, format, and display the 20 subsystem 160. The interface network 120 employs perim- 

contents of the retrieved subscriber information. Such lan- eter router 122 to interface with the wireless communication 

guages may include Hypertext Markup Language (HTML), system 100, which transports the IP datagrams between the 

Handheld Markup Language (HDML), Extensible Markup remote access device 104 and the BSC/MSC 106. The 

Language (XML), Extensible Stylesheet Language (XSL), interface is achieved by virtue of a WAN topology and may 

and Wireless Markup Language (WML). 25 employ well-known Asynchronous Transfer Mode (ATM), 

2. Network Access to Data Center Frame Relay, dedicated DS-1 (1.544 Mbps), DS-3 (45 

As stated above, the remote access devices 104 have Mbps) and other topologies. The perimeter router 122 may 

communication capabilities to interface with a variety of connect to the data center 190 through a firewall 124 to 

communication networks, including wireless communica- provide an added level of protection and further limit access 

tion systems. FIG. IB illustrates the basic elements of a 30 to data center 190 from the Internet. Artisans of ordinary 

wireless implementation of network 100 in FIG. 1A. Arti- skill will readily appreciate that generally, firewalls are 

sans of ordinary skill will readily appreciate that these well-known security mechanisms that protect the resources 

elements, and their interfaces, may be modified, augmented, of a private network from users of other networks. For 

or subjected to various standards known in the art, without example, enterprises that allow its own subscribers to access 

limiting their scope or function. 35 the Internet may install a firewall (or firewalls) to prevent 

In one implementation, the remote access device 104 first outsiders from accessing its own private data resources and 

communicates and sustains a session with a Base Station for controlling what outside resources its own subscribers 

Controller/Mobile Switching Center (BSC/MSC) 106 via have access to. Basically, firewalls filter incoming and 

the wireless interface (i.e., air-link) U m in accordance with outgoing network packets to determine whether to forward 

a wireless communication network scheme, such as CDPD, 40 them toward their destination. 

CDMA/IS-95, TDMA/IS-136, MOBITEX, and GSM. The The firewall 124 interfaces with the login subsystem 140. 

BSC/MSC 106 employs a transceiver to transmit to the As depicted in FIG. 1C, the login subsystem 140 comprises 

remote access device 104 (i.e., forward link) and receive a login server (LS) 142, and an attributes database server 

from the remote access device 104 (i.e., reverse link), 144. In one implementation an external disk array 146 may 

consistent with the wireless network scheme. The BSC/ 45 be used to store the database information. 

MSC 106 supervises, manages, and routes the calls between The firewall 124 is connected to the LS 142. The LS 142 

the remote access device 104 and the Inter- Working Func- provides a centralized login site for all subscribers and 

tion (IWF) 108. provides the first level of subscriber authentication. As such, 

The IWF 108 serves as a gateway between the wireless all sessions stemming from subscribers' remote access 

system 100 and other networks. The IWF 108 is coupled to 50 devices 104 are first handled by the LS 142. The LS 142 is 

the BSC/MSC 106 and in many cases it may be co-located configured as a web server, such as MICROSOFT® Internet 

with the BSC/MSC 106. The IWF 108 provides the session Information Server (IIS) for remote corporate enterprise 

between the remote access device 104 and the BSC/MSC access. The IIS is designed to be tightly integrated with 

106 with an IP address, consistent with the well-known MICROSOFT® Windows NT Server, resulting in faster 

Internet Protocol (IP). 55 Web page serving. The LS 142 may be implemented as a 

As is well known in the art, the IP protocol is a network single IIS or as a cluster of IISs with load balancing and fault 

layer protocol that specifies the addressing and routing of tolerant features provided by MICROSOFT® Windows 

packets (datagrams) between host computers and specifies Load Balancing Service (WLBS). 

the encapsulation of data into such packets for transmission. The LS 142 communicates with an attributes database 
Addressing and routing information is affixed in the header 60 server 144, which provides, inter alia, subscriber credential 
of the packet. IP headers contain 32-bit addresses that profiles to authenticate each subscriber. (The attributes data- 
identify the sending and receiving hosts. These addresses are base server 144 may also contain subscriber display prefer- 
used by intermediate routers to select a path through the ences and customized enterprise display features). The sub- 
network for the packet towards its ultimate destination at the scriber credentials are stored in the external disk array 146, 
intended address. Providing the session between the remote 65 which is coupled to the attributes database server 144. The 
access device 104 and the BSC/MSC 106 with an IP address, attributes database server 144 may be configured as a 
the session can be intelligently routed to other networks. Structural Query Language (SQL) database server and may 
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be implemented as a single server or as a cluster of servers 
with cluster management provided by MICROSOFT® Clus- 
ter Server (MSCS). 

FIG. 2 illustrates the LS 142 authentication process. As 
shown in block B205, subscribers input an address or URL, 
corresponding to an enterprise network or sub-network 
therein, in the browser interface of their respective remote 
access devices 104. Generally, inputting a valid URL point- 
ing to a particular enterprise network 403 in the remote 
access device 104 browser establishes a session between the 
browser and the LS 142. 

The LS 142 responds by sending a message back to the 
remote access device 104 browser, prompting the subscriber 
to supply login credentials and a personal identification 
number (PIN), as indicated in block B210. The login cre- 
dentials may include subscriber-name and password while 
the PIN is used as a second level of authentication by the 
enterprise network 403. Id block B215, the LS 142 examines 
the login credentials. The LS 142 then determines, as shown 
in block B220, whether the account is locked out. As a 
security measure, an account is locked out if a predeter- 
mined number (e.g., 3) of successive bad login attempts 
occur. If the account is locked out, the LS 142, in block B225 
informs the subscriber that the account has been locked out. 
LS 142 examines the information. If the account has not 
been locked out, the LS 142 advances to block B230. 

In block B230, the LS 142 compares the examined login 
credentials with the subscriber credential profile. The sub- 
scriber credential profile contains subscriber-specific 
information, which resides in the attributes database server 
144. In block B230, the LS 142 determines whether a match 
exists between the session-provided information and the 
stored credential information. If a match does not exist, the 
LS 142 progresses to block B235, where it first determines 
whether the current request constitutes the third bad login 
attempt. If so, the account is locked, as stated above with 
respect to block B220. If the request does not constitute the 
third bad attempt, then the LS 142 advances to block B245, 
where it requests the subscriber to re-input the login infor- 
mation and PIN. 

If a match does exist between the session-provided infor- 40 
mation and the stored credential information, the LS 142 
associates the identified subscriber with a corresponding 
enterprise network 403 (as indicated by the information 
contained in the URL, subscriber credentials, or a combi- 
nation thereof), thereby achieving the first level of 45 
authentication, as depicted in block B250. It is noted that the 
existence of a subscriber in the attributes database server 
144 is preferably keyed to both the entered subscriber-name 
and the enterprise network 403 associated with the sub- 
scriber. Accordingly, different enterprise networks 403 can 
have the same subscriber-name. 

Upon successfully authenticating the subscriber, the LS 
142, in block B260, encodes the session with a subscriber- 
specific, session-specific, and time/date-specific enterprise 
access code (EAC). This is achieved by providing the 
browser on the remote access device 104 with the EAC as 
well as the address information (i.e., URL) for the dedicated 
server (i.e., EGS), within the service subsystem 160, that 
points to the enterprise network 403. The LS 142 then 
informs the dedicated server of the impending session and 
provides the server with the EAC. Subsequently, in block 
B270, the LS 142 dynamically redirects the session to the 
dedicated server and upon recognizing the EAC session, the 
dedicated server grants access to the redirected encoded 
session. 

As depicted in FIG. 1C, the data center 190 includes a 
service subsystem 160. The service subsystem 160 com- 
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prises a plurality of dedicated web servers, wherein each 
server accesses and services a specific enterprise network 
and a plurality of attributes database servers 166 which 
service the dedicated servers. These dedicated web servers 
are referred to as enterprise gateway servers (EGSs) 164. 
FIG. 3 illustrates that each EGS 164 comprises a 
MICROSOFT® Internet Information Server (IIS), a plural- 
ity of application interfaces 307, and an associated attributes 
database server 166. Much like the LS 142, the EGS 164 
may be implemented as a single IIS or as a cluster of IISs 
with load balancing and fault tolerant features provided by 
MICROSOFT® WLBS. 

The application interfaces 307 provide the functionality 
and interoperability between the EGS 164 elements, the LS 
142, and the attributes server 144. The application interfaces 
307 comprise a plurality of COM (Component Object 
Model) objects 308 and Active Server Pages (ASPs) 306 that 
are specifically designed to achieve EGS 164 functionality. 
The COM objects 308 (described in more detail below) are 
reusable program building blocks that can be combined with 
other components in a distributed network to form func- 
tional applications. The ASPs 306 are server-side scripts that 
are capable of generating markup languages, including but 
not limited to HTML, HDML, WML, XSL, XML, etc., to 
perform the dynamic rendering of web content which can be 
delivered to any browser. The ASPs 306 work with in 
conjunction with the COM objects 308 to capture the 
contents of the enterprise network 403 information and 
dynamically output the information on the browser display 
of the remote access device 104. 

The ASPs 306 are designed to first retrieve the subscriber 
display preferences from the attributes database server 144 
to determine how to render the information on the browser 
display of the remote access devices 104. These preferences 
include attributes relating to the formatting, filtering, and 
sorting of the information. By way of example, suppose a 
subscriber wishes to retrieve e-mail information from his 
inbox, which is stored in the messaging database server 
(e.g., MICROSOFT® Exchange Server 5.5) within the 
enterprise network 403. After inputting the necessary HITP 
URL in the remote access device 104 to access the enterprise 
network 403, a session is established with the LS 142. The 
HTRP header of the request contains information identifying 
the particular remote access device 104 used in entering the 
URL. An ASP 306 exploits this information to determine 
what type of markup language (e.g., HTML, HDML, WML, 
XSL, XML, etc.) to use in rendering the display of the 
desired e-mail information. 

As stated above, after establishing subscriber 
authentication, the LS 142 redirects the session with a URL 
that points to an ASP associated with a dedicated EGS, along 
with the type of information sought. In this case, the 
redirected URL may read as "enterprise__network_A/ 
emailasp", where "enterprise_jietwoikLA" is the name of 
the enterprise network 403 in which the EGS 164 points to 
and "email.asp" points to the ASP 306 responsible for 
retrieving and incorporating the subscriber-specified prefer- 
ences. These preferences identify how the e-mail informa- 
tion in the enterprise network 403 appears on the browser 
display of the remote access device 104. For example, the 
subscriber may want the unread inbox entries to be rendered 
first, followed by the subject of each entry, followed by the 
initials of the sender, followed by the time and date of 
transmission, etc. In one implementation, these preferences 
may be stored in the attributes data server 164 within the 
service subsystem 140; in another implementation, these 
preferences may be stored in the attributes data server 144 
within the login subsystem 140. 
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Before retrieving the desired information from the enter- 
prise network, the ASPs 306 are also responsible for vali- 
dating the session between the EGS 164 and the enterprise 
network 403. After being re-directed to a dedicated EGS 
164, a Virtual Private Network (VPN) connection is estab- 5 
lished to the enterprise network 403 and the session is 
extended thereto. As described in more detail below, the 
ASPs 306 must determine whether the VPN connection and 
the session between the EGS 164 and the enterprise network 
403 are valid. 10 

Finally, the ASPs 306 retrieve the desired information in 
raw form from the enterprise network 403 and format the 
raw information in accordance with the subscriber prefer- 
ences and remote access 104 device limitations. 

In addition to acting as an intermediary, the data center 15 
190 may act as a central repository for the subscriber 
information. In this manner, the data center 190 provides 
subscribers with "enterprise-like" functionality by hosting 
subscriber information (e.g., such as e-mail, calendar, and 
phone book information) that would otherwise be stored in 20 
an enterprise network 403. This may be achieved by incor- 
porating a messaging server, such as MICROSOFT® 
Exchange Server 5.5, within the data center 190. 

Much like the "intermediary" case, the subscriber initiates 
a request in the remote access device 104 and the data center 25 
190 receives the request, establishes a session with the LS 
142, and authenticates the subscriber. However, as indicated 
in FIG. 1C, instead of the LS 142 re -directing the session to 
an EGS 164 connected to a remotely-situated enterprise 
network 403, the LS 142 accesses the desired subscriber 30 
information from the local messaging server 148 within the 
data center 190 that hosts such information. One implemen- 
tation includes re-directing the session to a web server 147, 
which is coupled to the local messaging server 148, in a 
manner similar to the EGS 164. By virtue of the application 35 
interfaces (similar to the EGS application interfaces 307) 
designed to the provide functionality between the LS 142, 
the attributes server 144, and the messaging server 148, the 
desired information is retrieved and rendered in accordance 
with the display capabilities of the remote access device 104. 40 

Further, based on the information received from the 
remote access device 104, including the HTTP header of the 
request, the login subsystem 140 determines the type of 
remote access device addressing the data center 190. The 
login subsystem 140, particularly the login server 142, 45 
translates the HTTP header received and provides data and 
a subscriber interface in accordance with that device type. 
For example, if the subscriber has indicated her preference 
for receiving ten e-mail headers when accessing the system 
with her remote access device 104, and the login server 142 50 
receives the HTTP header and a request for e-mail, the 
system will only seek to transmit ten e-mail headers for the 
subscriber. 

4. Data Center and Enterprise Network Interaction 

As previously discussed, consistent with an aspect of the ss 
present invention, the data center 190 retrieves data 
requested by remote access devices 104 from an enterprise 
network 403 and returns the requested data, in real time, to 
the remote devices 104 (i.e., the data center acts as an 
intermediary). A more detailed description of the interaction 60 
of the data center 190 with the enterprise network 403 will 
now be described with reference to FIGS. 4-7. 

FIG. 4 is high level diagram of data center 190 coupled, 
via network 402, to a plurality of enterprise network servers 
403. Network 402 may be a network such as the Internet or 65 
a proprietary local area or wide area network. Data center 
190 links multiple heterogeneous remote devices 104 to one 
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of enterprise network servers 403. At the request of one of 
remote devices 104, data at an associated enterprise network 
server 403 is transferred over network 402 to data center 
3190, where it is converted to a form suitable for display by 
the requesting remote device. 

Each enterprise network server 403 is a computer or 
network of computers managed by a corporation or other 
entity that implements corporate messaging and collabora- 
tion applications such as email, calendar, or contact infor- 
mation management applications. These applications are 
implemented by messaging server 410, which may be a 
dedicated messaging and collaboration server such as a 
server running MICROSOFT® Exchange Server 5.5 on top 
of the MICROSOFT® Windows NT operating system. 
MICROSOFT® Exchange Server and MICROSOFT® Win- 
dows are available from MICROSOFT® Corporation, of 
Redmond, Wash. Other known implementations of the mes- 
saging and collaboration servers may equivalently be used. 

Remote Gateway Servers (RGS) 415 are preferably 
implemented as servers that act as an intermediary between 
messaging servers 410 and data center 190, Although the 
messaging servers 410 could communicate directly with 
data center 190, remote gateway servers 415 provide a layer 
of abstraction between the messaging servers and the data 
center 190 that enables more efficient communication when 
communicating over a "slow" network such as the Internet. 
RGSs 415 are described in more detail below. RGSs 415 
may optionally not be used, in which case, the messaging 
servers 410 communicate could communicate directly with 
data center 190. For the reasons discussed below with 
reference to FIGS. 7A and 7B, this has been-found to be a 
less efficient implementation. 

If network 402 is a public network, such as the Internet, 
data transmitted over network 402 is at risk of being 
intercepted or monitored by third parties. To avoid this 
problem, the data may be encrypted at its transmission site 
(e.g., data center 190 or enterprise network server 403), and 
correspondingly decrypted at its reception site. By encrypt- 
ing all data transmitted over network 402, data center 190 
and enterprise server 403 effectively communicate with one 
another as if they were on a private network. This type of 
encrypted network communication is called a virtual private 
network ("VPN"). 

FIGS. 5Aand 5B are block diagrams illustrating embodi- 
ments of the implementation of a VPN between data center 
190 and enterprise network 403. The VPN is implemented 
by encrypting information transmitted between EGS 164 
and its corresponding RGS 415 on enterprise network server 
403. 

As shown in the embodiment of FIG. 5A, EGS 164 
encrypts the transmitted data using software 510 running on 
the EGS. The encrypted data is transmitted over network 
402 and decrypted by dedicated VPN server 515. Data 
flowing from enterprise network server 403 to data center 
190 is similarly encrypted at VPN server 515 and decrypted 
by software 510. Firewall 520 may optionally be imple- 
mented in conjunction with VPN server 515 to limit unau- 
thorized outsiders from accessing the private data resources 
of enterprise network 403 and to control what outside 
resources users at enterprise 403 have access to. Firewalls 
are well known in the art. 

One example of appropriate encryption/decryption soft- 
ware 510 is software that implements the well-known Point- 
to-Point Tunneling Protocol (PPTP). Although PPTP soft- 
ware 510 is shown executing on a VPN server 515 and EGS 
164, it may alternatively be implemented in special purpose 
PPTP routers or other network devices. 
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FIG. 5B illustrates another embodiment implementing a which CDO 701 is shown communicating directly with 

VPN between data center 190 and enterprise network 403. messaging server 410 across the Internet. However, because 

This embodiment is similar to the one described with CDO 701 generates multiple individual requests 705 for 

reference to FIG. 5A, the primary difference being that the what can often be represented by a single request (e.g., CDO 

IPSEC (Internet Protocol Security) standard is used to s 701 generates separate network requests to retrieve the 

encrypt/decrypt data instead of the PPTP standard. As subject and the time that ao email is sent, while practically, 

shown, encryption using IPSEC is implemented by a pair of these requests may both be submitted at the same time), 

complementary routers 525. delays can occur when accessing messaging server 410. In 

The IPSEC standard is known in the art. In contrast to the particular, when, as shown in FIG. 7A, CDO 701 is located 

PPTP standard, the IPSEC standard can provide encryption 10 across a relatively slow or unreliable network such as the 

at the session layer or the network packet processing layer. Internet, generating multiple requests at CDO 701 can cause 

PPTP provides encryption at the session layer. Additionally, significant delays in the overall response time. For example, 

the IPSEC standard offers considerably more options in the if there is a quarter second delay associated with transmit - 

implementation of bulk encryption or hash algorithms. ting a request over the Internet, one request for a message 

RGS 415 communicates with data center 190 through the 15 from message server 410 may be acceptable, while 40 partial 

VPN. Although RGS 415 may be typically present at the requests for the same message may result in an unacceptably 

same location as the corporate network, RGS 415 and data long delay to retrieve the message. 

center 190 are preferably given limited access to messaging Consistent with an aspect of the present invention, a 

server 410 as well as any other corporate servers. Id DCOM stub object 605, executing locally on RGS server 

particular, RGS 415 is only given the authority to commu- 20 415, and a DCOM proxy object 607, executing on EGS 

nicate with messaging server 410 to the extent necessary to server 164, introduce a layer of abstraction between CDO 

retrieve and store data related to the messaging and collabo- object 604 and EGS server 164. More particularly, DCOM 

ration applications implemented by messaging server 410. stub 605 and DCOM proxy object 607 communicate with 

Thus, even though RGS 415 may be given limited access to one another over network 402 using a higher level, less 

messaging server 410 and the rest of enterprise network 403, 25 messaging intense protocol than that used by CDO 604 

it is generally physically located at the site of the enterprise when communicating with messaging server 410. Instead of 

network 403. issuing multiple requests over network 402 to retrieve a 

FIG. 6 is a diagram of a more detailed architectural view particular e-mail's header, time stamp, priority, and body, 

of the software components used to implement RGS 415. DCOM proxy 607 may issue a single aggregate request for 

As shown, RGS 415 provides a MAPI (Messaging Appli- 30 all the information associated with one email, or for the first 

cation Programming Interface) interface 602, MAPI 602 is ten emails. DCOM stub 605 receives the single request from 

a MICROSOFT® Windows program interface that enables DCOM proxy 607 and converts it into the appropriate CDO 

software objects on RGS 415 to communicate with a MAPI- calls. Data received back from CDO 604 is similarly aggre- 

compliant information store, such as MICROSOFT® gated into the higher-level protocol and transmitted back 

Exchange messaging server 410. MAPI 602 provides the 35 across network 402 to DCOM proxy 607. Because CDO 604 

low level interface between RGS 415 and messaging server executes locally with messaging server 410, multiple calls to 

410. MAPI 602 accesses messaging server 410 based on the messaging server do not significantly slow system 

commands from CDO (Collaboration Data Objects) object response time. 

604. CDO 604 is an object in the COM (Component Object In addition to handling CDO call aggregation, DCOM 

Model) framework for the development of component soft- 4Q proxy 607 and DCOM stub 605 manage the connection over 

ware objects. COM provides the underlying services of network 402. Once EGS 164 instantiates DCOM proxy 607, 

interface negotiation, life cycle management (determining DCOM proxy 607 establishes a dedicated VPN session 

when an object can be removed from a system), licensing, connection ("tunnel") 608 between DCOM proxy 607 and 

and event services (putting one object into service as the DCOM stub 605. After establishing a VPN connection, 

result of an event that has happened to another object). 45 DCOM stub 605 receives the subscriber's PIN from DCOM 

MAPI, the COM framework, and the CDO object are all proxy 607. The PIN is passed to Lightweight Directory 

available from MICROSOFT® Corporation. Access Protocol (LDAP) object 609, which retrieves a 

CDO 604, in operation, processes requests from data locally stored copy of the subscriber's PIN and compares it 
center 190 to access messaging server 410. Typical CDO to the copy received from enterprise gateway server 164. By 
requests include requests such as: retrieve the message 50 comparing PINs at the enterprise, a second level of sub- 
object for a particular email of a particular subscriber, scriber authentication is achieved. The values of the PINs 
retrieve the subject of the email, and retrieve the time the are controlled locally at enterprise server 415. Accordingly, 
email was sent. For each of these requests, CDO 604 system administrators at the enterprise server have control of 
accesses messaging server 410, retrieves the requested the second authentication level, and therefore final control 
information, and returns the information to the requesting 55 over which subscribers are allowed to access the enterprise 
entity. network information. 

Objects in the conventional COM framework, such as From the point of view of EGS 164, CDO object 604 is 

CDO 604, are limited to communicating with other objects executing locally at data center 190. EGS 164 accesses 

on the same server. COM may be extended to access and use DCOM proxy 607 as if it were a locally executing CDO 

resources present at server program objects on other com- 60 object. Proxy 607 converts the CDO requests from EGS 164 

puters in a network using the DCOM (Distributed Compo- to the previously mentioned higher level, less message 

nent Object Model) framework. DCOM is available from intensive protocol, and transmits the request through the 

MICROSOFT® Corporation. session tunnel 608 to DCOM stub 605. Thus, calls across 

CDO 604, operating under DCOM, may be stretched network 402 are handled transparently to EGS 164. 

across network 402 so that requests for messaging server 65 Additionally, dropped or lost tunnels to DCOM stub 605 are 

410 are initiated by a CDO object resident in EGS 164. This reinitiated by DCOM proxy 607 and DCOM stub 605 

implementation is conceptually illustrated in FIG. 7A, in without involving EGS 164. 



07/02/2004, EAST Version: 1.4.1 



US 6,563,800 Bl 



15 



FIG. 7B is a conceptual diagram illustrating the commu- 
nication path between messaging server 410 and EGS 164 
when DCOM proxy 607 and DCOM stub 605 are used. As 
shown, CDO 604 communicates with messaging server 410 
using multiple CDO requests 712. DCOM stub 605 aggre- 
gates the results of a number of CDO requests and transmits 
it to DCOM proxy 607 over an encrypted session tunnel. 
Proxy 607 converts the aggregated results into CDO mes- 
sages for EGS 164. 
5. Additional Attributes 

The system further includes the ability to personalize or 
customize the subscriber interface based on the status or 
desire of the subscriber or the enterprise network 403. For 
example, the party maintaining the enterprise network 403 
may wish to introduce certain graphics or data when a 
subscriber logs in or seeks data from the enterprise. Coupled 
with this is the desire of a subscriber to configure his or her 
account to show certain information; for example, when the 
subscriber is operating a device at his workplace, he may 
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ELEMENTNAME 


SortOrder Note 


Example 


CarricrBanncrLog 


1 


HTML 


<img src» M images/default 








/att_Jogo.giT> 


MainBgColor 


1 


Hex 


#FFFFFF 






Coloi 




PpcBannerLogo 


5 


Text 


Revolv Home 


HdmlPhoneAboutTbct 


A 


HDML 


<LINE>Wireless 








Knowledge <LINE>LLC 



The system stores the customized elements are in the 
CustomElements table that maintains a correlation between 
a specific Customization ID and all of the customizable 
element names and their associated values. By having the 
CustomElements table track elements as name/value pairs, 



elements may be removed or added without modifying the 
wish to only receive work related e-mail. Alternately, the 20 table structure. Element values can be HTML, HDML, 



subscriber may have language preferences or screen style 
preferences that he or she wishes to view on particular 
devices. 

The subscriber enters his preferences, which are stored in 
the SQL server in the login subsystem 140. These features 25 
may include background color, primary and secondary 
colors, or other preferences for the subscriber interface. 
When the subscriber accesses the service, the login server 
142 receives the carrier, enterprise, language, and browser 
information from the signal received. 30 

The set of customizable elements are identified by a 
sequence called the customization ID. The customization ID 
represents a unique combination of carrier, enterprise and 
language desired by the particular enterprise. When a user 
logs into the system, their customized look and feel is 35 
determined by matching their carrier, enterprise and lan- 
guage preferences to the master set of customization IDs. 
The system then fetches the matching custom elements. The 
customized elements are inserted into ASPs at specific 
locations, thereby altering the look and feel of the system. 

In many cases, enterprises do not customize every pos- 
sible element of the service but simply change a small subset 
such as the banner logo and primary colors. In these cases 
where many elements are not customized, default values are 
retrieved so that the entire look and feel is preserved when 45 
the page is being internally "assembled/' 

The custom elements themselves are not fetched directly 
from the SQL Server during runtime but are stored as a 
structured array of values in memory on the server. Running 
in memory provides increased performance by minimizing 50 
database queries for custom elements. The customization 
system "refreshes" itself during runtime by updating the 
in-memory structure arrays from the data in the SQL Server 
database. Changes to the customization system are therefore 
available real-time without the need to restart the system. 

The system maintains a Customization table, which 
includes a correlation between a specific combination of 
Carrier, Enterprise and Language and a unique Customiza- 
tion ID, i.e., [Provider X; Company Y; French Canadian] is 
CustomizationID #6. This combination of factors, or Cus- 
tomization ID, is in rum related to a set of customized 
elements. The number and variety of customizable elements 
can be extensive depending on resource availability, and can 
range from the background color of the page to the text 
within the subject header of the e-mail in box. The Custom- 
ElementNames table maintains the master list of all of the 
customizable elements supported. 



XML, hex values plain text or any other textual information. 
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TABLE 2 




CUSTOMELEMENTS TABLE 


CUSTOMIZATIONID ElementName 


ElementValue 


1 


CarrierBannerLo go 


<img src="images/default/ 






WKBanner.jpg" 






widthV'270" height="70" 






border="0"> 


1 


PhoneHomeTitle 


Revolv Home 


5 


CarrierB annerLogo 


<img src="images/bm/ 






ServicePTOvider- 






XBanner.jpg" 






widthV'300" beLght="70" 






border-" 0"> 


6 


PhoneHomeTitle 


Service ProviderXl 



When a user logs in, the system obtains the user's 
CarrierlD, EnterpriselD and Language ID from her record in 
40 the Users table. The system then compares these three values 
against the Customization table, looking for a match. If an 
exact match is not found, the system searches for the closest 
match in the following order of precedence: 

a. Look for a matching CarrierlD, EnterpriselD, and 
LanguagelD 

b. Look for a matching CarrierlD, EnterpriselD and 
default language 

c. Look for a matching CarrierlD, no enterprise and 
LanguagelD. 

d. Look for a matching CarrierlD, no enterprise and 
default language 

e. Use the default look and feel 
Based on the closest match, the system determines the 
CustomizationID. As may be appreciated, the enterprise 
dictates certain components of the Customization ID. 
Should no enterprise dictated parameters be available, the 
system may provide the user with the ability to dictate 
preferences for appearance, and if the user has not indicated 
the information, the default appearance is presented to the 
user. 

Application startup procedures are presented in FIG. 8. 
On application startup, the system builds the pCustomiza- 
tionlndex array 801 by parsing the Customization table 802 
and ordering the CustomizationlD's sequentially. This array 
will later be used as an "row index" for the pElementValues 
array 806. The system then builds the pElementNames array 
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803 by parsing the CustomElementNames table 804. The 
pElementNames array 803 serves as the "column index" for 
the pElementValues array 806. The system then populates 
the pElementValues array 806 by parsing the Custom- 
Elements table 805. Each row of the pElementValues array 5 
806 corresponds to a specific element found in the pEle- 
mentNames array 803, and each column of the pEle- 
mentValues array 806 corresponds to a specific Customiza- 
tionlD from the pCustomizationlndex array 801. The 
CustomElements table 805 is parsed and the values are 10 
positioned within the pElementValues array 806 according 
to the ElementName and CustomizationID for each record. 

Once the system has populated the pElement Values array 
806, the array is parsed and each row is, stored in a variant 
array 807. Each variant array is then stored in an Application 15 
variable with the same name as the array element, i.e., 
Application ("CarrierBannerLogo"). 

Each application includes the customization library in its 
global variable definitions. This file contains all of the 
functions needed by customization. The Application^. 20 
OnStart subroutine calls the initCustomization( ) function, 
which performs the first-run parsing of the database tables 
and the storage of the customized elements into Application 
variables. This function loads the latest customized elements 
from the database and populates Application variables with 25 
variant arrays containing these elements. 

The system determines the user's CustomizationID by 
examining her CarrierlD, EnterpriselD and LanguagelD and 
finding the CustomizationID that is the closest match. Once 
the CustomizationID has been determined, the system com- 30 
pares it to the Customizationlndex array to determine which 
array positions contain the customized elements for this 
user. This derived value is called the User Customization 
Index value and is stored in a Session variable (or carried 
along the query string for Phone code). The 35 
getUserCustomizationIndex( ) function returns a value rep- 
resenting the ordinal position of customized elements for the 
particular user. Since all of the customizable elements of the 
service are stored as variant arrays within Application vari- 
ables for each application they are easily accessible from 40 
ASP. Each page that needs customization must have the 
getElement( ) function included, which returns a string value 
representing the customization element for a specific Cus- 
tomization ID. For efficient operation, each occurrence of a 
hard-coded element (HTML or otherwise) must be replaced 45 
with the getElement( ) function. Each web application needs 
to have an ASP page that calls the initCustomization( ) 
function, passing an argument to display the customized 
contents as they are populated into Application variables. 

The system further provides for notification in circum- 50 
stances where the user requests to be notified on a particular 
input device under predetermined conditions. When the 
subscriber receives a communication that he or she has 
established to be important, such as an e-mail message 
having a designation of urgent, the system attempts to notify 55 
the subscriber. The subscriber states his or her preferences 
for notification, such as what events trigger a notification 
and which input device or devices should be notified of the 
triggering event. These notification indications are main- 
tained in the SQL server at the data center 190, and this 60 
information is periodically monitored. As may be 
appreciated, only certain events will require user notifica- 
tion. With data information limited to e-mail, calendar, and 
contacts, notification will not be required for contacts, and 
certain e-mail requests may require notification. Calendar 65 
items may also prompt notification. In such circumstances, 
the user preference may require monitoring at the remote 
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enterprise by passing the requested notifications to the 
remote enterprise location. Alternately, notification may 
monitor user requests at the data center 190, with requests 
periodically transmitted to the enterprise servers. The prob- 
lem with maintaining the information at the data center 190 
and transmitting requests to the enterprise server is over- 
head. In the scenario where the data is provided to the 
enterprise server, the enterprise server maintains the prefer- 
ences for all users in its domain, such as notification of an 
urgent e-mail, and when the condition is true, passes infor- 
mation to the data center 190. Data center 190 correlates the 
notification with the various input devices requested to be 
notified by the user, and transmits the data to the user input 
device requested. 

A further aspect of the current system is the ability for the 
system to determine the type of device accessing the system. 
For example, the system receives information over a data 
line including initialization information, account 
information, passwords, and so forth, in addition to browser 
information. Browser information includes the information 
requested for the type of browser used, e.g. a 
MICROSOFT® Windows CE device indicates that it is 
using a Windows CE compliant browser. Included in the 
browser information is header information from which the 
data center 190 can determine the type of device transmit- 
ting the data. The data center 190 stores the information 
expected to be received from a particular browser; for 
example, the Netscape browser, used on desktop and laptop 
devices, may include the word "mozilla" in its header 
information. The data center 190 maintains predetermined 
expected header parameters for each anticipated input 
device. This predetermined information is maintained in the 
SQL server. Upon connection between the input device and 
the data center 190, the data center retrieves the browser 
header information and compares this information with the 
predetermined information and, if it determines a match, 
interfaces with the input device with input device specific 
data, e.g. screen size limitations, colors/greyscale data, and 
so forth. Thus the system does not require user input to 
determine the type of device addressing the data center 190 
and can transmit appropriate input device specific data to the 
user. 

Further, as may be appreciated from the foregoing 
description, the data center interacts with the enterprise 
network by transmitting requests to the enterprise network 
and receiving responses therefrom. As may be appreciated, 
a user desiring access to the data center will in most 
circumstances also wish to have access to the enterprise 
network. For security reasons, an enterprise network may 
not wish the data center to directly access the enterprise, and 
will not automatically grant access. Most enterprise net- 
works will have firewalls installed to prohibit access by 
unknown parties. 

The system accepts passwords for access to the data 
center and the user logs into the data center. Subsequent to 
this logon, the system knows the enterprise where the user 
may access information based on the user's profile. The user 
then is provided by the data center to the enterprise network, 
where the user must log into the enterprise. This will 
typically be a different user name and a different password. 
Certain password evaluation algorithms are employed by the 
data center to guard against access by unauthorized parties. 
However, under all conditions, the data center never obtains 
the user's enterprise password, but merely passes the user's 
password through to the enterprise without storing or evalu- 
ating the information. 

The foregoing description of preferred embodiments of 
the present invention provides illustration and description, 



07/02/2004, EAST Version: 1.4.1 



US 6,563,800 Bl 



19 



20 



but is not intended to be exhaustive or to limit the invention 
to the precise form disclosed. Modifications and variations 
arc possible consistent with the above teachings or may be 
acquired from practice of the invention. Accordingly, the 
scope of the invention is defined by the claims and their 
equivalents. 

What is claimed: 

1, A data center providing access to subscriber informa- 
tion maintained on a remote enterprise network, the data 
center comprising: 

a data network interface system for interfacing with a data 
network; 

a login system including a login server for receiving a 
request inputted by a subscriber on a remote access 
device across the data network to access the subscriber 
information and for authenticating the subscriber and 
the remote device; and 

a service system including a plurality of enterprise gate- 
way servers for transmitting the request to the remote 
enterprise network across a second data network to the 
remote enterprise network and for receiving the 
requested subscriber information from the remote 
enterprise network across the second data network; 

wherein the login server dynamically redirects the remote 
access device to a corresponding enterprise gateway 
server associated with the enterprise network upon 
authenticating the subscriber and the remote access 
device and the corresponding enterprise gateway server 
establishing a virtual private network (VPN) connec- 
tion with the remote enterprise network across the 30 
second data network and communicating with the 
remote enterprise network; 

wherein the login system further includes an attributes 
database server hosting subscriber credentials for 
authenticating the subscriber, the attributes database 35 
server being accessed by-the login server; 

wherein the service system includes application interfaces 
which operate with the login server, the attributes 
database server, and the plurality of enterprise gateway 
servers, to identify the remote access device, to process 40 
the authentication of the subscriber and the remote 
access device, to dynamically redirect the remote 
access device to the corresponding enterprise gateway 
server, to establish the VPN connection between the 
corresponding enterprise gateway server and the 
remote enterprise network, and to transmit the 
requested subscriber information to the remote access 
device; 

wherein the application interfaces are further configured 
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6. The data center of claim 5, wherein the attributes 
database server is configured as a Structured Query Lan- 
guage (SQL) server. 

7. A data center providing access to subscriber informa- 
tion maintained on a remote enterprise network, the data 
center comprising: 

a data network interface system for interfacing with a data 
network; and 

a login system including a login server and a data center 
messaging server, the login server receiving a request 
inputted by a subscriber on a remote access device 
across the data network to access the subscriber infor- 
mation and authenticating the subscriber and the 
remote device, the data center messaging server hosting 
the subscriber information, 

wherein the login server, upon authenticating the sub- 
scriber and the remote device, accesses the subscriber 
information on the data center messaging server and 
provides the subscriber information to the remote 
access device in response to the received request; 

wherein the request to access the subscriber information 
conforms to a Hypertext Transfer Protocol (HTTP) 
request and includes information referencing the data 
center, information identifying the type of remote 
access device, and information identifying the sub- 
scriber information; 

wherein the data network is a wireless communication 
network; 

wherein the login server, upon receiving the HTTP 
request, transmits a message to the remote access 
device prompting the subscriber to input login creden- 
tials; 

wherein the data network interface system includes at 
least one of a firewall and a perimeter router for 
restricting access across the wireless network; 

wherein login server accesses an attributes database 
server hosting subscriber credentials for authenticating 
the subscriber; and 

wherein the data center includes application interfaces 
which operate with the login server and attributes 
database server to identify the remote access device, to 
process the authentication of the subscriber and the 
remote access device, to access the subscriber infor- 
mation on the data center messaging server, and to 
transmit the requested subscriber information to the 
remote access device. 

8. The data center of claim 7, wherein the application 



to transmit the subscriber information request to the 50 interfaces are further configured to transmit the subscriber 



remote enterprise network across the VPN connection, 
to receive the requested subscriber information from 
the remote enterprise network messaging server across 
the VPN connection, and to format the requested sub- 
scriber information. 
2. The data center of claim 1, wherein the VPN connec- 
tion is configured in accordance with one of Point-to-Point 
Tunneling Protocol (PPTP) standard and Internet Protocol 
Security (IPSEC) standard. 



information request to the data center messaging server and 
to receive the requested subscriber information from the data 
center messaging server. 

9. The data center of claim 8, wherein the application 
55 interfaces comprise a plurality of component object model 

(COM) objects and active server pages (ASPs). 

10. The data center of claim 9, wherein the login server is 
configured as web server. 

11. The data center of claim 10, wherein the login server 



3. The data center of claim 2, wherein the application 60 is configured as an Internet Information Server (IIS), 
interfaces comprise a plurality of component object model 12. The data center of claim U, wherein the attributes 
(COM) objects and active server pages (ASPs). database server is configured as a Structured Query Lan- 

4. The data center of claim 3, wherein the login server and guage (SQL) server. 

the enterprise gateway server are configured as web servers. 13. The data center of claim 12, wherein the data center 

5. The data center of claim 4, wherein the login server and 65 messaging server is configured as an Exchange Server, 
the enterprise gateway server are configured as 

MICROSOFT® Internet Information Servers (IISs). # + * * * 
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